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ABSTRACT 


Naval Surface Warfare Center Port Hueneme Division identified the need for an 
improved ship-to-shore data transfer capability in order to meet future data demands. The 
demand for a better ship-to-shore data transfer system has been a growing concern in 
recent years, primarily due to the increasing complexity of combat system elements. 
These data needs, coupled with advancements in communication technology, will aid in 
providing an effective and efficient data-transfer system beyond the current limitations of 
bandwidth. One approach to enhance data transfer capability and supplement existing 
methods of ship data transfer is the use of unmanned systems as either a primary or 
secondary means of communication. This capstone delivers a concept of operations, 
system architecture, and modeling and simulation analysis for a conceptual system 
intended to meet the United States Navy’s need of increasing ship-to-shore data transfer 
capability. The results shown in the conceptual application of this approach yield a 
significant operational time reduction when compared to the current method of data 
transfer. Supported by simulation and data analysis, this reduction in operational time 
achieves positive results for both the feasibility of using an unmanned aerial vehicle and 


increasing the capability for ship-to-shore data transfer onboard Navy vessels. 
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EXECUTIVE SUMMARY 


This capstone was developed in response to a need for an improved ship-to-shore 
data transfer capability in support of United States Navy (USN) test events, identified by 
the Naval Surface Warfare Center Port Hueneme Division (NSWC PHD). Specifically, 
there was a demand for a faster data transmission method to augment existing ship-to- 
shore communication networks to support USN test events. Test event analysis and 
distance support efforts necessitate tremendous amounts of data to be transferred to and 
from shore-based activities. Data transfer constraints imposed by existing 
communications systems can prohibit the possibility of timely test event data analysis and 
distance support efforts. Test events are typically conducted post ship delivery or after an 
availability period where major system upgrades are implemented. With the current goal 
of a 355-ship fleet (O’Rourke 2020) and increasing complexity of ship systems, there will 
be consistent and immediate demand for an improved data transfer capability to support 
test events for the foreseeable future. In response, the capstone team captured relevant 
information to develop the capstone problem statement: 

The demand for a better ship-to-shore (bidirectional) data transfer system 

has been of paramount concern in recent years, primarily due to the 

increasing data needs of combat system elements. These data needs 

coupled with advancements in communication technology will aid in 


providing improved decision-making support and operational capabilities 
beyond the current shipboard system limitations. 


The capstone team identified a technological opportunity to fill this capability gap 
by leveraging capabilities of existing unmanned aerial vehicle (UAV) platforms to 
facilitate a supplementary line of communication capable of fulfilling stakeholder 
requirements. Additionally, this system would have to operate in environmental 
conditions associated with USN test events, interface with operators at the ship and 
ground station, establish and maintain a bidirectional data connection as required between 
the ship and ground station, and have the capability to interface and write data to 
approved removable media. A conceptual system design was created, named Deployable 


Aerial Datalink (DAD), with the intent to show that utilizing a UAV platform can 
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achieve stakeholder objectives. This system was intended to provide increased 
availability of data from ship-to-shore. The DAD system operational concept consists of 
using removeable media provided by ship’s force to upload to an external system, which 
will then communicate with a bolt-on subsystem deployed on a UAV for data upload or 
relay. In Figure 1, a USN ship equipped with a DAD modular computer subsystem is 
utilizing the DAD system line of communication to receive or transmit data from the 
DAD modular computer subsystem via the UAV equipped with a DAD bolt-on 


subsystem. 


1.3 UAY with: Bolt-On System 
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Figure 1 - DAD Operational View 


The capstone team used a tailored Systems Engineering Vee model during system 
conceptualization, adapted from International Council on Systems Engineering 
(INCOSE) and Wiley (2015). The study produced a concept of operations, technical 
approach, set of feasible candidate solutions, system architecture, system model and 
simulation, and feasibility results. The derived conceptual system was an aggregate of 
analysis of existing communication methods and related systems paired with the 


operational objectives. An analysis of alternatives (AoA) was conducted and four 


XX 


potential solutions were identified for analysis; (1) keep using the existing satellite 
technology, (2) using a UAV as a relay, (3) using a UAV for receipt and transmission, 


and (4) using a UAV for data upload and hard drive removal. 


From the derived system requirements, a physical architecture was developed by 
applying partitioning criteria to translate requirements into system functions. System and 
subsystem functions were then further decomposed, and feasibility criteria was applied to 
develop a physical system architecture. Functions, interfaces, and system composition 
were further defined and captured in the system architecture for which the capstone team 
used the model-based systems engineering (MBSE) tool Innoslate to create the 
conceptual system. Figure 2 provides a high-level DAD system block definition diagram 


(BDD). 
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Figure 2 - DAD System BDD 


With system requirements and system architectures defined, a modeling 
methodology was determined in order to derive expected system performance. The 
modeling and simulation tool ExtendSim was used to analyze relationships between 
operational time and data rates using specific scenario conditions. Analyses supported the 
use of UAVs as a data transfer platform and revealed preferable system configurations 
and system employment methods. Preliminary findings showed promise that the 
conceptual systems utilizing UAVs have potential to deliver an increased data transfer 


capacity over existing communications systems at a lower operational cost to the USN. 
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I. INTRODUCTION 


A. PROJECT OVERVIEW 


This capstone report is a result of a collaboration effort formed between Naval 
Postgraduate School (NPS), Naval Surface Warfare Center Port Hueneme Division 
(NSWC PHD), and Project/Program Manager, Ship (PMS) 500, to address the issue of 
existing fleet data transfer limitations. The issue addressed in this report was presented to 


the NPS Systems Engineering (SE) 311—192S cohort capstone team by NSWC PHD. 


NSWC PHD provides the United States Navy (USN) surface fleet with 
integration, test and evaluation (T&E), life-cycle engineering, and product support for 
today’s and tomorrow’s warfare systems. NSWC PHD participates in numerous 
certifying events such as combat system ships qualification trials (CSSQT) and various 
other developmental and operational test events (Commander Naval Sea Systems 
Command 2020a). As one of the sponsors of NSWC PHD, PMS 500 “manages the 
design and construction of destroyers, amphibious ships, special mission and support 
ships, as well as a wide range of boats and craft for United States (U.S.) agencies and 


foreign military sales” (Commander Naval Sea Systems Command 2020b). 


The capstone team employed a combination of various engineering disciplines 
(aerospace, computer, mechanical, industrial, and marine engineering), experience 
supporting the Department of Defense (DOD), research, and subject matter expert (SME) 
input to develop a potential solution to address an existing data transfer capability gap to 
support USN test events. The principal goals of this capstone were to investigate the 
feasibility of utilizing unmanned aerial vehicles (UAVs) to improve ship-to-shore data 


transferring capabilities and develop a conceptual deployable datalink system. 


B. BACKGROUND 


As described in ‘A Design for Maintaining Maritime Superiority’ version 2.0 and 
the DOD modernization strategy, the global threat landscape is continually changing and 
the U.S. no longer has the competitive advantage in all areas, making it crucial to 


modernize our digital world to maintain competitiveness. To ensure advantage in all 
1 


areas (Department of Defense 2019), the focus must include the role of data in decision 
making (United States Chief of Naval Operations 2018). USN involvement in 
maintaining a competitive advantage is instrumental and as a maritime nation, the USN 
must increase naval power and warfighting capability through “improved readiness and 
reliability of systems to ensure combat mission capable ships” (Naval Sea Systems 
Command 2019). Availability of data is at the center of ensuring ships’ combat readiness 
and meeting the DOD modernization strategy, as it enables “identification needed for 
subsequent actions, lessons learned, design of improved tactics and systems” (Duren and 
Pollard 1991), along with “improved decision making support and enhanced operational 


capabilities” (Office of the Chief Information Officer 2000). 


As the In-Service Engineering Agent (ISEA) for multiple USN surface ship 
combat system elements, NSWC PHD provides distance and on-site support, training, 
troubleshooting, maintenance, and other logistics and engineering functions. Increased 
availability of data will enable NSWC PHD to more effectively perform ISEA functions 
by bypassing typical delays in receiving data and ultimately will contribute to combat 
system readiness. Typical delays include data shipment and waiting for ships to return 


from deployment. 


C. PROBLEM OVERVIEW 


USN T&E events generate immense quantities of data, due to the increasing 
complexity of modern Naval combat systems. Post-event analysis and distance support 
efforts require combat system data to be transferred from ship to ground-based activities. 
Bandwidth limitations imposed by existing methods of data transfer can affect the 
timeliness of associated analysis required for test event certification or distance support. 
These issues are central to the vision statement provided by the capstone vision owners: 

Transferring data from ship-to-shore has been and continues to be a 

challenge for the USN. Unless we come up with a dynamic solution, soon, 

we will carry this problem onto new developments/platforms. The idea 

behind this project is to develop a system capable of transferring classified 

and unclassified data from an UAV to a shore-based site. Although 


intended for UAVs, the system should also be compatible with other 
platforms with minimum to no impact to the platform’s infrastructure. 
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In line with NSWC PHD’s role with providing T&E and direct fleet support to 
surface ships, the intent of this project is to conceptually design a data transfer platform 
for UAV deployment to enable faster availability of data for analysis (Commander Naval 
Sea Systems Command 2020a). The concepts fundamental to design of the data transfer 
platform included being standalone and external to ships’ infrastructure. This design 
concept addressed one of the challenges identified by the National Research Council 
(NRC). According to the NRC, the U.S. continues to struggle to meet the changing needs 
of ship communications due to constraints regarding available space for communication 
suites and upgrading infrastructure to rapidly expanding needs (National Research 
Council 2000). Another important aspect of the conceptual system is the intent to provide 
a method of ship-to-shore data transfer additional to existing ships’ communication 
capabilities. As stated in the 2020 USN Information Superiority Vision, a major 
challenge the USN faces with the transfer of data from ship-to-shore is bandwidth 
limitations. The path for the data to transit is too constrained to achieve data transfer in 
time requirements(Office of the Chief Information Officer 2020). One approach to 
enhance data transmission capability is to supplement existing methods of ship-to-shore 


data transfer through use of UAVs as communication nodes. 


The capstone team developed a system concept named Deployable Aerial 
Datalink (DAD) to address the deficiencies identified by the capstone vision owners. 
Accounting for resources and schedule, the capstone team limited the project scope to 


preliminary design of the DAD system concept. 


D. PROJECT OBJECTIVES 


The primary objective of this capstone was to investigate the feasibility of 
utilizing a UAV as a communication node for ship-to-shore data transfer. A secondary 
objective for this capstone was increasing data availability to ultimately contribute to 
combat system readiness. A tertiary objective was to provide NSWC PHD and other 
DOD activities with a feasible option to supplement existing data transfer methods. The 
last objective of this capstone was to provide NPS and NSWC PHD with the deliverables 
identified in Table 1. 


Table 1. | Capstone Deliverables 








Analysis of A comparison and evaluation of alternative solutions 

Alternatives that meet desired stakeholder capabilities. 

Architecture A graphical representation that defines the structure of 
the system. 

Concept of A description of integrated system characteristics and 

Operations objectives from the stakeholder perspective. 





Literature Review 


A review of available scholarly resources related to the 
system concept. 





Requirements 





Definitions of various system functional and non- 
functional needs. 











E. TEAM STRUCTURE 


Team Rico organization was structured as shown in Figure 1. Each team member 


was designated responsible for at least one section, and each team member was expected 


to contribute to remaining sections. High level descriptions of roles and responsibilities 


for each project area are described in Table 2. 


Team Lead 





Antoin Abboud 
Katrina Granada (co-lead) 
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J 
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| 








Requirements 
Engineering 


Wesley Sanders 
Alex Kemeny 








Architecture 
Design 


Jacob Shadle 
Antoin Abboud 





Analysis of 
Alternatives 


Edwin Laboy 
Wesley Sanders 





Technical 
Editor 


Katrina Granada 
Alex Kemeny (co-editor) 





Figure 1. 


Team Rico Structure 


Table 2. Team Roles and Responsibilities 


Project Led the development of the capstone project and was the focal 
Lead point for communication with project sponsors; was 
responsible for setting expectations and direction for the team 
during the project, developed a project plan, managing 
deliverables, assign tasks to team, and provided updates on a 
regular basis to advisors; was responsible for keeping team 
members and stakeholders informed of key developments and 
any changes in the project plan; was responsible for 
mitigating any risk involved as the project progresses 
Engineering Included responsibility of gap analysis associated with 
Analyst alternative solutions; identified risks associated with each 
alternative solution 
Tech Writers/ | Included responsibility of overall project documentation and 
Editors ensured proper spelling, grammar, and formatting; tasked 
with project report management and submission to the Thesis 
Processing Office (TPO) 
System Included responsibility for the design and documentation of 
Architects system interface, key system components, and infrastructure; 
tasked with the overall design of the system and ensuring 
modeling of system meets technical and functional 











requirements 
Requirements | Included definition, documentation, and requirements 
Engineers maintainment; modeling and simulation; analysis of 


stakeholders needs and conversion to requirements into a 
standard format. 














F. STAKEHOLDERS 


A list of stakeholders and their primary areas of interest are identified in Table 3. 
The most important stakeholder identified is the Fleet, as the main goal of increasing 
availability of data is to contribute to Fleet readiness through improved ISEA support. 
Other stakeholders for this capstone include NSWC PHD, not only as the vision owners, 
but as the command that plays a vital role in supporting combat and weapon systems 
during T&E and ISEA activities; Naval Sea Systems Command (NAVSEA); and 
Program Executive Offices (PEOs) (Commander Naval Sea Systems Command 2020a). 


Table 3. Capstone Stakeholders 


Fleet Improve combat and weapon system readiness, 
increase availability of system data for 
decision making 

NSWC PHD Increase availability of combat and weapon 
system data to improve readiness, increase 
knowledge, improve ISEA support 











NAVSEA Improve fleet readiness, increase ISEA 
effectiveness and support, reduce total 
ownership cost (TOC) 

PEOs Improve fleet readiness, reduce combat 











system failure trends, reduce TOC 





G. SUMMARY 


Maintaining maritime advantage continues to drive the USN to seek new and 
improved methods of increasing naval power and warfighting capability. Increased 
availability of data from ship-to-shore contributes to warfighting capability through 
combat system readiness and enabling ISEAs to better effectively address life cycle 
issues. The purpose of this capstone was to investigate the feasibility of increasing data 


through use of UAVs as nodes between ship-to-shore data transfer. 


HW. TECHNICAL APPROACH 


The intent of the DAD system is to increase fleet data transfer capabilities using 
UAVs. In order to realize this intent, this project used the SE methodology in line with 
the concepts outlined in the International Council on Systems Engineering (INCOSE) 
handbook (INCOSE and Wiley 2015a). The same INCOSE handbook provided the 


following explanations of SE terminology: 


SE is an interdisciplinary approach and means to enable the realization of 
successful systems. It focuses on defining customer needs and required 
functionality early in the development cycle, documenting requirements, 
and then proceeding with design synthesis and system validation while 
considering the complete problem... A life cycle can be defined as the 
series of stages through which something (a system of manufactured 
product) passes... Functionality of a system is typically expressed in terms 
of the interactions of the system with its operating environment, especially 
the users...System architecture is the fundamental concepts or properties 
of a system in its environment embodied in its elements, relationships, and 
in the principles of its design and evolution... The Vee model is a 
sequential method used to visualize various key areas for SE focus, 
particularly during the concept and development stages. 


A. SCOPE 


For this capstone, the Vee model aligned best with the expected deliverables as it 
provided the framework for system conceptualization. The capstone team tailored the 
Vee model to fit the unique requirements of conceptualizing the DAD system, as seen in 
Figure 2 and Figure 3. The scope of this capstone only considered the left side of the Vee 
model and included aspects of key SE processes defined by INCOSE (2020): 


Establishing stakeholders’ success criteria and concerns, and defining 
actual or anticipated customer needs and required functionality, early in 
the development cycle, and revising them as new information is gained 
and lessons are learned...Investigating the solution space, proposing 
alternative solution and operational concepts...Architecting a solution or 
set of solutions based on the selected concept(s)... Modeling (or otherwise 
evaluating) the solution at each relevant phase of the endeavor...in order 
to establish required capability and performance; increase confidence that 
the solution will work as expected and required...Providing the SE 
knowledge and information required by all stakeholder groups to ensure 
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coherence of the whole endeavor — typically including a vision statement, 
operational concepts, architecture definition. 


System Development, , 
Define System Full System Operation 
Requirements, and Verification 
CONOPS 


Integration, verification, validation pper Level System 


Upper Level System Realization, 
Requirements and Verification of 


Design, AoA system 


Integration, verification, validation 


Sub-System 
Requirements, Realization, 
Component Detailed Verification of 





Figure 2. Tailored Vee Model. Adapted from INCOSE and Wiley (2015a). 
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Figure 3. Tailored Vee Model Detail. Adapted from INCOSE and Wiley 
(2015a). 


In conjunction with the tailored Vee model, the capstone team developed a work 
breakdown structure (WBS) to further detail the SE method. Figure 4 shows the high- 
level processes used to define stakeholder needs through system architecture design and 
solution recommendation. Table 4 lists the tools used to perform the SE processes 


outlined in Figure 4. 


B. PROCESS 


The first step taken to define stakeholder needs was to translate the stakeholders’ 
vision statement into the capstone problem definition and capstone objectives. This 
process required review of existing technologies in the fields of ship-to-shore 
communications, ship to UAV, UAV to shore communications, and bandwidth 
limitations. The development of the concept of operations (CONOPS) for the DAD 


system resulted from this process. 





1.0 Define 
stakeholder needs 


1.1 Research 
stakeholder needs 


1.2 Conduct needs 





2.0 Requirements 
Analysis 


2.1 Define system 
requirements 


2.2 Define functional 





3.0 System 
Architecture Design 


3.1 Develop system 
architecture with 
Innoslate 


3.2 Recommend a 
solution for 


Nnalysi f iremen F j 
analysis equirements implementation 


1.3 Develop 2.3 M&S using 
CONOPS ExtendSim 


2.4 Conduct AoA 





Figure 4. High Level WBS 


The next phase in system conceptualization was requirements analysis. During 
this phase, the capstone team identified system and operational requirements through the 
analysis of the existing technology review and decomposition of stakeholder needs. 
ExtendSim software application was utilized to create a mathematical model of the DAD 
system and simulated the effects of inputs on output performance (Law 2013). Another 
aspect of the tailored SE process during the requirements analysis phase is the analysis of 
alternatives (AoA). The AoA enabled evaluation of solutions generated to meet DAD 


system requirements and identified associated potential risks (AcqNotes 2018b). 
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Table 4. Tools Used 








Microsoft Word Word processor software used for document 
creation and editing. 

Microsoft Excel Spreadsheet software used for data visualization, 
analysis and calculations. 

Microsoft Project Project management software used to outline 


milestones, deliverables, budget, schedule, and 
project progress. 























Microsoft Power Point Presentation software used to present project 
briefings. 

Microsoft SharePoint Cloud service used for file sharing and storage. 

Innoslate Architecture and system modeling software tool 
used to create diagrams, drawings, and schema of 
the project. 

ExtendSim Simulation software used for modeling and 
optimization. 





The process of system architecting builds upon the derived system requirements 
to develop an architecture as a foundation to guide system design (The MITRE 
Corporation 2013). In line with DOD architecture framework 2.0, the team utilized a 
multi-step process to develop the architecture framework, as seen in Figure 5. These steps 
included determining the intended use of the architecture, determining the architecture 
scope, determining data required to support architecture development, collecting 
architecture data, conducting analysis of architecture objectives, and presenting results in 
accordance with decision-maker (or stakeholder) needs (Office of the Deputy Chief 
Information Officer 2020). Innoslate modeling software was used to create the 


architectural views that are later provided in this report. 
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Figure 5. Architecture Development Six-Step Process. Source: Office of the 
Deputy Chief Information Officer (2020). 


C. ASSUMPTIONS AND CONSTRAINTS 


The team developed the following set of assumptions and constraints applicable 


to this capstone scope: 


1, Assumptions 


The intent of the system is to supplement existing methods of data 


transfer. 


The intent of the system is to be temporarily deployed on USN surface 


vessels for CSSQTs or other test events. 
2 Constraints 


Capstone schedule has limited the scope of system development. 
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System concept will include use of UAV as directed by vision owners. 


Depth of system concept development is limited to keep capstone 


unclassified. 


The team did not have the ability to purchase, manufacture, prototype, 
functionally test, or verify the system outside of conceptualization and 


model-based systems engineering (MBSE) methods. 


Assumptions regarding the operation of the DAD system are listed in Chapter III, 


Section A. 


D. SUMMARY 


The scope of this capstone included SE activities found in the left side of the Vee 
model, including system development, definition of system requirements, a CONOPS, an 
alternatives analysis, and preliminary system architecture. The required tasks for the 
capstone were broken down into three main focuses; defining stakeholder needs, 
requirements analysis, and system architecture design. Assumptions and constraints 


applicable to the scope of the capstone were identified. 


13 


THIS PAGE INTENTIONALLY LEFT BLANK 


14 


Hi. LITERATURE REVIEW 


The purpose of this literature review was to research current knowledge and 
identify knowledge gaps. It includes scholarly reports, scientific journals, technological 
patents, and academic theses. The research was divided into three sections to enable 
greater understanding of the different components that are covered by the scope of the 
capstone project. These documents were analyzed with specific focus on how the 
capstone team could apply the information to the DAD system. The first section 
summarizes studies found regarding design considerations. The second section covers 
performance parameters which focused on findings of effectiveness and efficiency for 
different data transfer methods. The third section compiles a list of UAV characteristics 


and performance specifications 


A. DESIGN CONSIDERATIONS 


Creed and Glenn (2000) were able to transfer data in real-time using radio 
frequency (RF) links. In order to establish ship-to-shore data communication, each vessel 
had its own local area network (LAN) which communicated with the shore command 
center via FreeWave Spread Spectrum Data Transceiver/Ethernet bridge. During their 
effort, requirements were that it must have high speed data transfer, be able to transfer 
data over a 20-mile distance and be low cost. Based on their requirements, FreeWave 
Technologies Spectrum Wireless Data Transceivers provided capabilities required (Creed 


and Glenn 2000). 


Jawhar, Muhamed, Trabelsi and Al-Jaroodi (2016) explored the significance of 
UAV’s in wireless signal networks (WSN) for data collection as a median between relay 
nodes (RN) and distribution sinks/Network Collection Centers (NCC). Using a series of 
UAV algorithms, they developed models that compared the data collection strategies 
across multiple testing parameters, including UAV flight routes (constant speed, variable 
speed, adaptable speed) and different data links (RN to UAV, UAV to sink). Such 
parameters are important to consider for relaying data from an AEGIS platform ship via 


UAV to a land-based site. With a Variable Speed UAV (VSU), the algorithms considered 
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both when the UAV was in communication with the RN, and when no communication 
was taking place. Once the data connection was made between the RN nodes and the 
UAV, Jawar explained that medium range protocols- such as IEEE.802.11- have a data 
rate ranging from between | megabyte per second (Mbps) and 70 Mbps, depending on 
the height of the UAV’s flight. Jawar concluded from the various models that the data 
transfer rate was dependent on the buffer size of the RN - as the buffer size increased the 
UAV could deliver more packets to sinks, but the average delay of receiving the data also 


increased (Jawhar et al. 2016). 


Frink (2005) introduced a patent for a data retrieval system which uses a UAV to 
retrieve collected data from at least one surface data collection instrument. Frink’s 
invention can be placed in a ship and other types of marine vehicles. He stated that 
satellite data retrieval was limited by at least three constraints: uplink time allocations 
must be monitored and adjusted frequently, limited time slots available, and required 
significant amount of power from ground station to communicate effectively. One of the 
features for this invention was eliminating the need for personnel to retrieve data on-site 
by launching a UAV to the ground-based data collection instrument which had a 


transceiver attached to it (Frink 2005). 


Wells (2010) discusses the major components associated with a high data rate 
architecture. These components include a power supply, data interface, modulator, 
demodulator, transmitter, receiver, combiner, and an antenna. According to Wells, the 
most important aspect of a power supply is that it has to have a high reliability as well as 
avoid power loss. The power supply must also “be designed to tolerate poor quality input 
power with high levels of noise and/or transient spikes and avoid feeding back noise or 
interference.” Techniques to increase “robustness of the data stream” were listed and 
include forward correction error (FCE), interleaving, and encryption. Four classes of 
modulation are examined; amplitude shift keying (ASK), frequency shift keying (FSK), 
phase shift keying (PSK), and quadrature amplitude modulation (QAM). An issue often 
faced with demodulation is discussed, multipath fading, as well as a common solution, 
adaptive equalization. The importance of a power detector is to control high power 
amplifier (HPA) output and output power. A concern for unregulated power output is the 
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possibility of violating licensing rules and interfering with other nearby wireless services. 
A critical aspect of a receiver is to control the gain of the amplifier, otherwise the signal 
is at risk for being distorted or the demodulator could be overloaded. Wells introduced a 
combiner as a method for efficient use of hardware, through utilization of one antenna to 
perform the actions of a transmitter and receiver. Antenna types are compared for 
different uses; including highly directional reflector and aperture for long-distance 
communications, and parabolic and flat panel for high capacity systems. Wells also 
discusses methods for achieving gigabit per second data rates. These methods include 
single channel transmission, adjacent channel transmission, dual-polarization 
transmission, dual channel dual polarization, data compression, and multiple-input 


multiple-output (MIMO) transmission (Wells 2010). 


B. PERFORMANCE PARAMETERS 


Yang (2018) proposed more effective data transfer means from a ship to coastal 
area by designing three different data structures. These data structures included one for 
RF and long-term evolution (LTE) based networks, one for satellite-based networks 
(conventional method), and the last for emergency alerts. In this study, Yang states that 
“satellite-based networks cover the entire ocean, but the costs are very expensive” (Yang 


2018). 


Johansen et al. (2014), developed experiments testing a UAV as a wireless relay 
between an autonomous underwater vehicle (AUV) and a local ground control station 
(GCS). Using geometric calculations to determine optimal data upload based on antenna 
location, along with constructing an IEE802.11 Wireless fidelity (Wi-Fi) modem link 
provided five test setups with results in average data rate between 326 kilobits per second 
(Kbps) and 790 Kbps. The conclusion showed the driver behind the reduction in data 
rates was the proprietary wireless system on the AUV that provided “a relatively low 
capacity wireless data link regardless of signal strength and quality,” from the 802.11 
standards of 11 Mbps to 54 Mbps (Johansen et al. 2014). 


Li et al. (2017), considered the potential of optical communications between a 


ground transmitter and a ground receiver by using a UAV. By utilizing orbital-angular 
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momentum (OAM) multiplexing, there was significant increased capacity of free-space 
data transmission to moving platforms. This free-space optical (FSO) communication 
system included the ground station as well as the OAM transmitter and receiver while the 
UAV hovered in the air. In the conducted experiments, the authors were able to measure 
a data transfer rate of up to 80 Gigabits per second (Gbps) over a short roundtrip link 
(100m) (Li et al. 2017). 


Burdakov et al. (2009), presented two algorithms that were capable of generating 
relays in order to transmit sensor information back to a ground station. For their thesis, all 
UAVs had the same range for communication. They explained that in order to minimize 
transmission degradation UAVs require line of sight communication, and, that even 
though it can be amended by increasing altitude, that will mean greater ranges (Burdakov 


et al. 2009). 


Tierney et al. (2012), compared data transfer protocols over high latency network 
paths in an effort to achieve efficient and high-performance data transfer. This study was 
focused on meeting expanding scientific data transfer needs for distributed architectures. 
Although Tierney, Kissel et al., found that typical data transfers had a 10 Gbps 
connection or had data transferred in parallel to circumvent bandwidth limitations, their 
evaluation showed the best per-stream performance was around 13 Gbps, including 40 
Gbps hosts. They recommended improvements to data transfer methods including the use 
of zero-copy systems over the typical send()/recv() and the use of remote memory direct 


access (RMDA) over converged ethernet (RoCE) (Tierney et al. 2012). 


In a UAV cellular communications study, Xiao, Xia, and Xia (2016) discussed the 
potential issues associated with utilizing a moving communication node. Some of the 
issues they identified included blockage, beamforming, and propagation loss. Significant 
signal degradation can occur when line of sight (LOS) from the ground-based station to 
the UAV is blocked by any structure, but the proposed solution to address this issue is to 
incorporate adaptive cruising algorithms. Xiao, Xia, and Xia identified thorough 
beamforming was found to be timely and costly due to a large number of directions for 
the antenna to train. A hierarchical beamforming structure was investigated and they 


recommended as a method to significantly reduce search time. Use of a directional 
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antenna was shown to contribute to higher powered received signals (Xiao, Xia, and Xia 


2016). 


C. UAV CHARACTERISTICS AND SPECIFICATIONS 


Table 5 compiles a variety of UAV physical characteristics and performance 


specifications. 


Table 5. UAV Characteristics and Performance Specifications 
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D. ALTERNATIVES 


In order to effectively find potential solutions for increasing availability of data 
through ship-to-shore data transfer, the capstone team adopted the AoA framework in 
Figure 6 identified by The MITRE Corporation (2013b). The capstone team identified 
objectives from the stakeholder vision statement and then defined analysis criteria. The 
capstone team also utilized the knowledge gained from the literature review and SME 
feedback to identify, assess, and compare alternatives. This section of the AoA identifies 
and describes the alternatives that were analyzed using modeling and simulation. 


Additional detailed analysis is provided in Chapter VI, Section B. 


















2.0 Establish analysis 
foundation/framework 


3.0 Identify and 


1.0 Plan define alternatives 


5.0 Compare 40 Assess 


are eae alternatives alternatives 





Figure 6. AoA Framework. Adapted from The MITRE Corporation (2013b) 


The research of design constraints, performance parameters, and UAV 
characteristics and performance aided the capstone team with identification of 
alternatives and important design considerations. Information provided by Johansen et al. 
(2014); Tierney et al. (2012); Jawhar, Muhamed, Trabelsi and Al-Jaroodi (2016); and Li 
et al. (2017) was found to be outside of the scope of the capstone. Information provided 
by Creed and Glenn (2000), Yang (2018), and Frink (2005) were important design and 
performance considerations but technologies discussed did not fit the scenario in which 
the DAD conceptual system was going to be utilized. Research by Xiao, Xia, and Xia 
(2016) was helpful to understand design considerations if utilizing a LOS with a 
directional antenna. Information provided by Wells (2010) was useful to understand 
important transceiver design considerations and limitations with range and environment. 


Data rates and data transfer technologies provided by wells in Figure 7 made a significant 
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contribution, as microwave technology provided the best potential for a data rates and 
was used as input for modeling and simulation. The data listed in Table 5 provided 
insight into bolt-on subsystem design constraints as well as flight time limitations for data 
transfer. The ranges identified for each UAV platform also provided insight into potential 
use beyond CSSQT scenarios, permitting a data transfer technology that can support 


longer ranges. 


Fixed Microwave (6 to 40 GHz) 
and mm-wave (> 60 GHz) 


802.11n WiFi (5.8 GHz) 








802.11a/b/g WiFi (2.4/5.8 GHz) 


Theoretical 
802.162 WiMAX (to 3.5 GHz) 
[] Practically realizable 
LTE 4G (to 2.5 GHz) 
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Figure 7. Theoretical and Practical Data Rates via Commercial Technology. 
Source: Wells (2010) 


Based on stakeholder feedback, DOD experience, CSSQT knowledge, and UAV 
operating knowledge, the capstone team prioritized communication range and potential 
data rate as focal aspects for alternative solution development. Alternative solutions 
regarding UAV or ship system integration were not developed or analyzed as they were 
considered high risk for schedule and cost. The alternatives analyzed were chosen based 
off limited integration requirements and potential for rapid development and deployment. 
As specified in the vision statement, the alternatives developed in addition to the baseline 


data transfer method were centered around UAV utilization. 


1. Alternative 1: Existing Satellite Technologies 


This alternative will keep the conventional satellite connection as the only method 
of ship-to-shore data transfer. This method is the control and the benchmark for 


comparison. Stakeholders identified current data transfer rates range from 9 — 12 Mbps. 
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25 Alternative 2: UAV as a Relay 


The second alternative identified is using a UAV-deployed DAD subsystem as a 
relay. This method is constrained by technology capability because the range at which the 
UAV is required to position is equidistant between ship-to-shore. The increase in distance 
rules out many data transfer technologies due to reduced capability at further distances, as 
well as some of the UAV platforms listed in Table 5 due to limited endurance and longer 
data transfer times. Also, increased distance requires greater power for data transmission 
over longer ranges, a design consideration that may impact UAV platform selection. This 


alternative enables bidirectional ship-to-shore data transfer. 


3. Alternative 3: UAV Wireless Receive and Transmit 


The third alternative is using a UAV deployed DAD subsystem with wireless 
technology for both receiving and transmitting functionality. This method is constrained 
by UAV platform range capability, as a wireless receive and transmit subsystem would 
enable the ship to be at a further distance from shore. This method is also constrained by 
UAV platform endurance due to the increased flight time associated with uploading and 
downloading data to/from the DAD system components. The ability to have the UAV in 
closer proximity to the ship widens the data transfer technologies available for utilization. 


This alternative enables bidirectional ship-to-shore data transfer. 


4. Alternative 4: UAV Wireless Receive and Land 


The fourth alternative is using a UAV-deployed DAD subsystem to wirelessly 
receive and store data from the ship onto a removeable hard drive, then return to base 
(RTB) for personnel to retrieve the hard drive. This method is constrained mainly by the 
size of the UAV-deployed DAD subsystem, as it cannot exceed maximum UAV payload 
capacity. The benefit to selecting this alternative is the potential avoidance of limiting 
UAV platform selection to those with greater endurance, as the UAV would only be 
required to transit to ship proximity for data upload and RTB for hard drive removal. A 
second benefit to selecting this alternative is also the avoidance of a more complicated 
UAV-deployed DAD subsystem design that accounts for data transmission. This 


alternative restricts data transfer from ship-to-shore and is not bidirectional. 
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5. Alternative 5: UAV Wireless Receive and Transmit + Land 


A fifth alternative identified is a combination of UAV wireless receive and 
transmit technology with a removeable hard drive. This method has the same constraints 
as Alternative 3 but has the benefit of hard drive retrieval in case of emergency. This 
method allows for the time saving benefits of alternative 4 but also for the transmission 
of data to the ship to support troubleshooting efforts, or as mission dictates. This 


alternative will not be analyzed as it will be covered through alternatives 3 and 4. 


E. SUMMARY 


Through the literature review, the capstone team was able to identify different 
data transfer methods, technologies, and alternatives to ultimately increase data transfer 
capability. In addition to the current USN date transfer method, alternatives identified 
were utilization of the UAV as a relay, for wireless receipt and transmission, and for 
wireless receipt and RTB. The research conducted and alternatives identified showcased 
important information about the design constraints associated with use of a UAV as a 
platform for data transfer. This literature review provides multiple perspectives on how 


the information found can be applied to the conceptualization of the DAD system. 
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IV. SYSTEM CONCEPTUALIZATION 


A. OPERATIONAL CONCEPT DEFINITION 


The capstone team developed a system concept that addressed the data transfer 
capability gap identified by the vision owners. In addition to increasing availability of 
data, the system concept was centered around modularity to avoid the complexities of 
integrating with at least two host platforms. As displayed in Figure 8, the DAD 


conceptual system is composed of: 


One ship-based modular, standalone computer system capable of having 


no direct interface with the ship’s combat system. 


One bolt on assembly unit external to the UAV, capable of having no 
direct interaction with the UAV’s systems. This bolt on unit will provide 
the capability of using the UAV as a communication node for data 


transfer. 


One ground-based modular, standalone computer system capable of using 


power provided by the ground station. 


Los Angeles” . 


; A 
i a z oon 
~~ 


bem AA 


11 US DAVY SHEP wth Mocaitiar Comparten Lath Systeme 





Figure 8. _ DAD Operational View 
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1. Benefits 


The operational concept of the DAD system was to transfer ship’s combat system 
data through utilization of UAVs outfitted with a bolt on deployable data transfer system, 
enable faster availability to data for SME analysis, and decrease elapsed time between 
events and decision making. The DAD system will increase ship-to-shore data transfer 


effectiveness through the following benefits: 


providing an additional method of data transfer redundant to existing 


methods 


providing an increase to battlespace awareness and an improvement to 


tactical decision making through faster availability of critical data 


fulfilling a capability gap identified by USN leadership through an 


increase in data transfer rate 


providing a system with the ability to update software and hardware at a 


faster rate and potentially lesser cost than existing shipboard systems 


2 Operations and Support Descriptions 


Operation and support of the DAD system involves participation from ship’s 
force (SF), DAD operators, UAV pilots, UAV launch and recovery team, element SMEs, 
and CSSQT team. SF will be responsible for maneuvering the ship to the best UAV link 
location and downloading the combat system data onto removeable media. The DAD 
operators will be responsible for uploading/downloading data and establishing 
communications with the bolt-on subsystem. The UAV pilots will be responsible for 
guiding the UAV to both ship-based and ground-based link locations and to the launch/ 
recovery site(s). The UAV launch and recovery team will be responsible for UAV 
preparation, launch, recovery, and any associated post flight requirements. The UAV 
launch and recovery team will also be responsible for mounting and unmounting the bolt- 


on DAD subsystem. The element SMEs will be receiving the downloaded data and will 
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perform analysis as required. The CSSQT team will be responsible for coordinating and 


executing the data transfer with all involved activities during at-sea events. 


1 1.2 1.3 14 15 


16 
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Figure 9. DAD High Level Activity Diagram 


Figure 9 shows the various phases associated with utilization of the DAD system. 
To accomplish data transfer from ship-to-shore via the DAD system, the following 


general actions have been identified: 
1. The CSSQT team, DAD SMEs, UAV teams, and SF will coordinate the 


planning and execution of using the DAD system for data transfer. 


2 Launch team will prepare UAV with the DAD bolt-on subsystem and will 
launch UAV. 


a. Ship’s technician will pull data from the combat system and will store on 


removeable media. 


4, Ship’s technician will provide the removeable media to the ship-based 
DAD operator. 
on Ship-based DAD operator will load the combat system data onto the 


modular computer subsystem. 


6. UAV will arrive at designated location; ship-based DAD operator will 
initialize communications with the DAD bolt-on subsystem and will begin 


data transfer process. 
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10. 


ine 


3. 


UAV will travel to a designated location near the ground station, ground- 
based DAD operator will initialize communications with the DAD bolt-on 


system and will begin data transfer process. 


Ground-based DAD operator will verify data transfer and download 


completion with ship-based DAD operator and UAV operator. 
UAV will continue mission or RTB for recovery. 


Ground-based DAD operator will upload combat system data to a 


designated server for combat system element SME access. 


Combat system element SME will analyze data and provide solutions/ 


recommendations to decision makers. 


Operational Assumptions 


To keep in line with the scope of this capstone and to simplify the operational 


process, the following assumptions were made with regards to transferring data via the 


DAD system: 


DAD system utilization will occur on a predetermined day during CSSQT 
execution, after completion of specified event(s). This will include all 


requirements relative to test range scheduling. 


The UAV that will carry the bolt-on subsystem will be identified prior to 


CSSQT execution during the course of planning phase. 


Data transfer was limited to combat system data but can be expanded to 


any data available for transfer via removeable media. 


The modular computer subsystem will utilize available shipboard 


removeable media to transfer and upload data. 


The ship will be responsible for properly handling the removeable media 


after the ship-based DAD operator has completed the data transfer. 
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No distinction was made between the transfer of classified and 


unclassified data. 


DAD system utilization was limited to use of one UAV, but multiple 
UAVs with bolt-on subsystems can be used as communication nodes to 


relay data from further distances. 
Data transfer will not exceed UAV loiter time. 


The ground-based DAD operator and applicable SMEs will have access to 


the same server. 


B. SYSTEM LIFE CYCLE 


DOD acquisition models subdivide the system life cycle into a set of basic steps 
that separate major decision milestones. The decisions of these milestones are based on 
the result of completed system objectives in the preceding life cycle phase, as shown in 


Figure 10. 


Disposal 





Sytems Aequistons 
Legend © = Decision Point aX = Milestone Decision C) = Major Review 


Figure 10. DOD Acquisition Management Model (DOD 5000.2). Source: 
AcqNotes (2018c). 





1. Materiel Solutions Analysis (MSA) Phase 
As identified by AcqNotes (2018d): 


The purpose of the MSA Phase is to analyze all potential material 
solutions for an identified need. This phase consists of an AoA and 
material solution activities to include measures of effectiveness, cost 
estimates, schedule, CONOPS and risk assessment. The goal of this phase 
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is to recommend possible solutions for further exploration in the 
Technology Maturation & Risk Reduction (TMRR) Phase. 


The MSA Phase for this capstone is divided into three stages: needs analysis, 
concept exploration, and concept definition. Given the scope of this capstone, project 
deliverables and objectives are met through the MSA activities, highlighted in Chapter 
IV, Section C through Chapter IV, Section E of this report, as well as the AoA in Chapter 
VI, Section B. 


During the MSA phase, cyber engineering (CyE) efforts focus on gaining an 
understanding of the system mission, operational environment, and the program’s risk 
management strategy. The CyE tasks for this phase include development of cyber 
functional requirements driven by assurance of mission critical functions, system 
categorization based on mission, and the initiation of security control selection. These 
functional requirements can serve as the baseline for the Cybersecurity Battle Plan, which 
includes a Cybersecurity Strategy, Program Protection Plan, Security Assessment Report 


and Security Authorization Package (Department of Defense 2015). 


a. Needs Analysis 


The capstone team conducted an extensive literature review and used stakeholder 
and SME feedback throughout the first phase of system conceptualization. As a result, 
the capstone team was able to identify existing operational deficiencies and capability 
gaps in current data transfer methods. “Without proper understanding of the user needs, 
any system runs the risk of being built to solve the wrong problems” (Fairley, Forsberg, 
and Madachy 2020). Section C, Needs Analysis, answered the questions “Is there a need 
for a new system?” and “How will this need be satisfied?.” The purpose of the needs 
analysis was to provide a description of capabilities needed in the system of interest 


(Sol). 


b. Concept Exploration 


The concept exploration phase provides an initial set of system performance 
requirements which will be measured later against a set of required capabilities and 


performance. This set of requirements are described in Section D for the DAD system 
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concept. Evaluation parameters were identified and deemed critical in order to evaluate 
system operational effectiveness. In order to proceed to the concept definition phase, the 
following elements needed identification: the system boundary, system functions, system 


elements, system sub-elements, and system element interactions. 


é. Concept Definition 


The goal of the concept definition phase is to identify a set of Sol functional 
specifications. Section E describes in detail the Sol’s intended usage and its capabilities. 
These sets of functional requirements described the DAD system operational intent and 
the capability that will be provided to its stakeholders. This phase delivered a set of 
architecture models created using Innoslate. For the AoA discussed in Chapter I, 
verification matrices were created and supporting details are provided with supporting 


details for each of the alternatives analyzed. 


2. Technology Maturation and Risk Reduction (TMRR) Phase 


As identified by AcqNotes (2018d), the purpose of the TMRR phase is to “reduce 
technology risks and to determine the appropriate set of technologies to be integrated into 
a future system that satisfies the needs. . . . This phase will consist of risk reduction, cost 
estimations, and programmatic activities.” The major product of the TMRR phase is 
competitive prototyping from which an applicable program office will determine at 


Milestone B which prototype will proceed as a funded, program of record. 


The continued development of the DAD system would allow government 
contractors to compete with government off the shelf (GOTS), commercial-off-the-shelf 
(COTS), or new development DAD system components. Based on the complexity and 
design requirements for the modular computers, multiple vendors could bid on any or all 


of the data transfer computer subsystems. 


During this phase, it is important to design hardware and software concepts with 
cyber capabilities in mind. In the case that the DAD system is fielded, stakeholders must 
analyze the best method to address obsolescence while accounting for both cost and 


schedule. With risk management, the system development team must consider the effects 
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of hardware and software obsolescence on the overarching acquisition process and cyber 


capability issues. 


= i Engineering and Manufacturing Development (EMD) Phase 


The purpose of the EMD phase is the realization of the system design. “The goal 
of the EMD phase is to complete the engineering development and proceed into 
production and development’(AcqNotes 2018d). Major activities in this phase include 
developmental testing (DT) and initial operational test and evaluation IOT&E) 
(AcqNotes 2018a). 


If the DAD system development continued to this phase, the selected prototype 
vendor(s) would be funded to further design and test through laboratory and experimental 
scenarios. DT and IOT&E at land-based test sites can showcase data transmission 
capabilities and can progress to sea-based testing when the system is demonstrated as 


mature. 


Regarding CyE efforts during this phase, the security T&E engineer must have 
security controls and requirements assessed, the cyber risk assessment updated, and the 
risk management framework (RMF) package submitted. It is critical that cyber 
capabilities maintenance procedures and manuals include system administration 
requirements, procedures for patching, virus scanning, antivirus signature updates, 


amongst others. 


4. Production and Deployment (PD) Phase 
Defined by AcqNotes (2018d), the objective of the PD phase is to: 


Achieve an operational capability that satisfies the users and mission 
needs. This phase consists of two efforts: low-rate initial production 
(LRIP) and full-rate production decision review (FRPDR). The phase will 
also include operational testing of the capability to determine its 
effectiveness. 


An operational DAD system finishes operational testing in a sea-based scenario 
with a USN vessel with full system validation, and the applicable program office will 


fully fund contractors to build and deploy DAD systems. 
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5. Operations and Support (O&S) Phase 


“The purpose of the O&S phase is life-cycle sustainment and disposal. The life- 
cycle sustainment activities overlap the FRPDR effort of the PD phase. The phase ends 
with the final disposal of a system” (AcqNotes 2018d). 


The sustainment efforts of the DAD system depend on a number of factors, 
including ISEA support, DAD system inventory across the U.S. fleet (potentially 
including Foreign Military Sales to allied nations), and adaptability of the system to 
upgrade across newer UAV platforms, hardware/software upgrades, and hardware/ 


software obsolescence. 


GA NEEDS ANALYSIS 


The objective of conducting a needs analysis is to identify that a valid operational 
need exists and that a new system will fulfill that need at an affordable cost with an 
acceptable level of associated risk. The needs analysis is critical in revealing why a new 
system is needed and allows for a conceptualization of a successful system to form in the 
minds of stakeholders by producing arguments that support the stated needs. The needs 
analysis should answer the following questions: (Blanchard and Fabrycky 2011) 


(1) What is required of the system in “functional” terms? 
(2) What functions must the system perform? 
(3) What are the “primary” functions? 


(4) What are the “secondary” functions? What must be accomplished to alleviate 


the stated deficiency: when must this be accomplished? 
(5) Where is it to be accomplished? 
(6) How many times or at what frequency must this be accomplished? 


As seen in Figure 11, the primary inputs of the needs analysis are operational 
deficiencies and technological opportunities. The team first derived inputs for the needs 
analysis from the provided vision statement, followed by a more in-depth exploration of 


background information, stakeholder needs, and a technical review. 
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Figure 11. Needs Analysis Phase in the System Life Cycle. Source: 
Kossiakoff (2011). 


Operational deficiencies were initially identified by the stakeholder vision 
statement and were further refined by follow-on research in the background and technical 
review. The primary operational deficiency identified was the demand for a faster data 
transmission method to augment existing ship-to-shore communication networks to 
support USN test events. Test event analysis and distance support efforts necessitate 
tremendous amounts of data to be transferred to ground-based activities. Bandwidth 
constraints imposed by existing communications systems can prohibit the possibility of 


both timely test event data analysis and distance support efforts. 


The capstone team identified a technological opportunity to fill this capability gap 
by leveraging capabilities of existing UAV platforms to facilitate a new line of 
communication capable of fulfilling stakeholder requirements. The capstone team set out 
to develop a novel system to augment existing USN communication systems with one 
that can handle the steep data transfer requirements associated with USN test events. 
Additionally, this system would have to operate in environmental conditions associated 
with these events, interface with operators at the ship and ground station, establish and 
maintain a bidirectional data connection as required between the ship and ground station, 
and have the capability to interface and write data to approved removable media. Test 
events are typically conducted post ship delivery or after an availability period, where 


major system upgrades were implemented. With the current goal of a 355-ship fleet 
34 


(O’ Rourke 2020) and increasing complexity of ship systems, there will be consistent and 
immediate demand for an improved data transfer capability to support test events for the 
foreseeable future. The majority of test events occur on ranges in U.S. territorial waters. 
These ranges have an existing infrastructure and established distances between ship 


operational areas and ground stations. 


Partitioning criteria was applied to translate that information into functions and 
further allocate those functions into subsections. System and subsystem functions were 
then further decomposed, and feasibility criteria was applied to formulate the feasibility 
of the DAD concept. The derived conceptual system was an aggregate of analysis of 


predecessors and related systems and paired with operational objectives. 


D. REQUIREMENTS ANALYSIS 


Maintaining progression through the systems engineering process, the 
requirements analysis phase examines the operational perspective of the DAD system and 
states requirements in terms of project objectives. The intent of the requirements analysis 
is to restate or amplify both the system capabilities and system operational effectiveness 
associated with the overall operational objectives. The analysis performed in this section 
is derived from the definition of stakeholder needs as well as background research 


applicable to system designs regarding UAV data transfer. 


The requirements analysis can be expanded into a process of tasks to transform 
the system capability inputs into more specific functional system performance 
requirements. By utilizing the Institute of Electrical and Electronics Engineers (IEEE) 
P1220, the capstone team was able to follow the systems engineering standard for 
performing a comprehensive process in completing the Requirements Analysis (Defense 
Acquisition University 2001). The capstone team tailored the list to consider all 


necessary DAD system requirements. 


1. Customer Expectations 


The vision owners for this project understood both the project objectives in their 


entirety and the validation process for the DAD system. Throughout our collaborative 


D> 


meetings they expected our evidence to achieve its intended use in the conceptual, 


operational environment within the academic timeframe allowed. 


22 External Constraints 


The list of external constraints can be sub-categorized by Academic Compliance 


constraints and System Capability constraints. 


a. Academic Compliance 


Given the educational aspect of this hypothetical data transfer system, the 
information released for viewing and referencing purposes to the general public must 
comply with DISTRIBUTION STATEMENT A: Available for Public Use (Defense 
Technical Information Center 2012) .This restricts sharing any potential classified, 


proprietary, operational or otherwise vulnerable data and information. 


b. System Capability 


The scenarios in which the DAD system operates involves the respective 
subsystems and their components to interact with both existing ship and shore software 
and hardware systems, which can limit the interface capabilities. There are additional 
cybersecurity risks to be considered when transferring classified data between ship and 


shore subsystems. 


3. Operational Scenarios 


In order to achieve the project objectives in the allotted academic timeframe, the 
operational scope consists of a small scale, single UAV to transfer data as a 
communication node from ship-to-shore, during a CSSQT or other test events. Chapter 
VI explains a post feasibility study that allows for expansion of the operational scenario 


capabilities. 


4. Utilization Environments 


The hypothetical operational scenarios include ideal maritime environmental 


conditions to transfer data from ship-to-shore during CSSQT or other test events. These 


36 


ideal conditions include daytime, clear weather (no low-pressure systems present in the 


operational area), with steady sea-state conditions. 


op System Boundaries 


There are multiple boundary considerations for this project- operational, 
hardware, software- that define the full capabilities of the DAD system. We have greater 
interest in the hardware and software boundaries of the system, as these are best 
represented by the systems architecture framework. The framework can outline the UAV, 
ship and shore subsystem locations and their physical components, including operators 
and removable media, as well as the operating system functional data paths within the 


communication relay of the system. 


Given the conceptual design scope of this project, physical interfaces were 
considered as a suggestion based on both ergonomic principles and existing shipboard 
installation availability. The physical configuration spaces on both ship and shore may 
allow a smaller subsystem that is deployable, with modularity and a quick setup. 


6. System Requirements 

System requirements were partitioned between functional and non-functional 
requirements. The capstone team developed the following requirements for the DAD 
system after multiple feedback discussions with subject matter experts on both UAV’s 
and communication relays: 

a. Functional Requirements 

Functional requirements were further decomposed in Chapter IV, Section E. 

System shall have a human interface for the ground-based and ship-based 


subsystems. 


System shall have a user-friendly graphical user interface (GUI) for the 


ground-based and ship-based subsystems. 
System shall operate in clear weather conditions. 


af 


System shall establish and maintain a bidirectional data connection. 
System shall receive/write data via authorized removable media. 


System shall have an operational availability of xx% (threshold) or xx% 


(objective). 


Bolt-on subsystem shall be able to withstand takeoff, landing, and in-flight 


conditions 
Bolt-on subsystem shall be deployable with xx minutes. 
Bolt-on subsystem shall be uninstalled within xx minutes. 


Non-functional Requirements 


System shall transfer data at a minimum rate of xx Mbps (threshold) or xx 


Mbps (objective) 


Ship-based modular computer subsystem shall utilize 110v electrical 


outlet. 
Systems shall encrypt data at rest on portable and removeable media. 


All DAD system sub-components shall have an encryption and decryption 


capabilities. 
System shall encrypt data in transit. 


Bolt-on subsystem shall have a minimum battery life of xx hours 


(threshold) or xx hours (objective). 
Bolt-on subsystem shall be under xx pounds (Ibs) and xx cubic feet (ft). 


Bolt-on subsystem shall be battery powered. 
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E. FUNCTIONAL ANALYSIS 


There is an importance to analyze what the system must do before describing how 
those system capabilities are to be completed. The Functional Analysis offers a 
decomposition of the system functional requirements through several subsystems 
arranged in a hierarchical structure (Whitcomb 2000). The DAD system can be 
decomposed into its modular and bolt on subsystems’ functional flow with respect to the 


functional requirements listed in Section D. 


1. Functional Flow Block Diagram (FFBD) 


Utilizing an FFBD relates the inputs and outputs of the DAD system while 
providing insight into the flow between the different system functions (INCOSE and 
Wiley 2015b). The conceptualized scenario involves data input from either a ship-based 
or ground-based user on the respective modular computer subsystem. That data package 
is sent from one modular subsystem through a UAV’s transmitter/receiver bolt-on 
subsystem as a relay for data retrieval to the other modular subsystem. A system level 


FFBD is illustrated in Figure 12. 


Ones SSS = 
Figure 12. DAD System Level FFBD (ship-to-shore data transfer) 


Figure 12 defines the functional scope of the DAD system, showing both 
communications between the ship and shore on UAV services, and the data transfer 
interactions between the modular and bolt-on subsystems. Note that this functional 
example did not implement bi-directional flow in the same diagram, but each of the 
functional steps would proceed in the same order had the shore requested UAV services 


to send data from the shore modular subsystem to the ship modular subsystem. 
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2s Functional Requirements Decomposition 


a. System shall have a human machine interface for both ground-based 
and ship-based subsystem 


For any ship test event, the process of communicating data starts with SF (both 
enlisted and officers) relaying data packages to be received and interpreted by 
government ISEAs. In order for the data to be extracted, both SF and ISEA must have the 
physical capability to access the means to insert/compress the data to be sent, as well as 


extract/decompress the relayed data package. 


b. System shall have a user-friendly GUI for the ground-based and ship- 
based subsystems 


To assist with efficient use of both computer subsystems, the GUI shall have an 


application that is easy to navigate with clear and concise information. 


c. System shall operate during clear weather conditions 


This requirement is necessary for reliably conducting data transfer operations 
using the DAD system. Inclement weather conditions provide increased risk for impaired 


data transfer capability, or event cancellation altogether. 


d. System shall establish and maintain a bidirectional data connection as 
required to both ground-based and ship-based subsystems 


The UAV will have a predetermined flight plan, based on the request from the 
ship. The UAV will proceed on course until in range to establish a data connection; the 
UAV would fly in a loitering pattern about the ship to ensure a stable connection to 
upload the data package. The ship would minimize its own change of course to keep a 
consistent loitering pattern. In the event of a loss of communications or loss of global 
positioning system (GPS) signal between the UAV and the ground operators, 
programmed protocols would guide the UAV back towards the ground station until 


communication link could be reestablished. 
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e. System shall receive/write data via authorized removeable media 


The DAD system is conceptualized around existing shipboard spaces and overall 


physical attributes, as well as hardware/software suites within the applicable combat 


system baseline. 
f System shall have an operational availability of xx% (threshold) or xx% 
(objective) 


Operational availability is a function of reliability, maintainability, and 
supportability. The better the operational availability, the greater the capability for the 
USN. (Office of the Chief of Naval Operations 2003) 


g. Bolt-on subsystem shall be able to withstand takeoff, landing, and in- 
flight conditions 


Exposure to extreme environmental conditions requires the bolt-on subsystem to 
be tested for shock, vibration, thermal cycling, salt-water, fog, electromagnetic 


interference (EMI), and others. 


h. Bolt-on subsystem shall be deployable within xx minutes 


UAV deployment is dependent on acceptable launch conditions, potentially 
decreasing the amount of time available to install the bolt-on subsystem. In order to be 
available for use during real time decision making, the bolt-on subsystem must be able to 


be installed within a given timeframe to avoid further launch delays. 


i. Bolt-on subsystem shall be uninstalled within xx minutes 


To be able to effectively maintain data control, is it important for the system to be 


easily uninstalled in order to perform any direct download or sanitization. 


F. SUMMARY 


The capstone team expanded the idea of a data transfer system into an operational 
concept that addressed the data transfer capability cap identified by the vision owners. 
Considering the program requirements of acquiring a future DAD system, a layout of the 


system life cycle was addressed by subdividing system deliverable across the multiple 
4] 


phases of DOD Acquisition. Given the conceptual scope of this project, most of the 
capstone deliverables were shown in the MSA phase. This included a needs analysis that 
identified an existing operational need and a concept exploration that included a 
requirements analysis restating both system capabilities and system operational 
effectiveness. Finally, a concept definition showed a functional analysis that described 


how the system capabilities were to be completed. 
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V. SYSTEM ARCHITECTURE 


System architecture provides a foundation for design and development through 
organization of system components, their relationships to each other and to their 
environment (The MITRE Corporation 2013). System architecture communicates the 
system’s design through visual representation of functionalities, interfaces, and 
requirements to ensure desired stakeholder requirements will be met. The architecting 


process also helps to define system constraints, boundaries, and additional requirements. 


The architecture for the DAD system was developed in accordance with (IAW) 
the DOD framework shown in Figure 5 (Office of the Deputy Chief Information Officer 
2020) using the MBSE tool Innoslate. Different system diagrams were developed in order 
to showcase the DAD system and its functionalities on a broader level. Systems modeling 
language (SysML) was used to create the following diagrams: requirements diagram, 
package diagram, block definition diagram, use case, activity diagram, and a sequence 


diagram. 


A. REQUIREMENTS DIAGRAM 


Development of the DAD system architecture began with the identification of 
system requirements. The purpose of requirements diagrams is to represent relationships 
between requirements, as well as partition those requirements into functional and non- 
functional groups (SysML.org 2020b). DAD system requirements were initially 
conceptualized by stakeholder needs and were refined through research and technical 
review. Figure 13 shows a high-level requirements diagram for the DAD system. System 
functional requirements define basic system behavior and for the DAD system included 
interface, operational environment, data transfer, UAV launch, and availability 
requirements. Non-functional requirements define how the system will perform its 
behavior and for the DAD system included performance, design, and software security 
requirements (QRA Team 2019). The requirements identified in Figure 13 were 


previously discussed in Chapter IV, Section D. 
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Figure 13. DAD System Requirements Diagram 


44 


B. HIERARCHY DIAGRAM 


The purpose of a hierarchy diagram is to show the Sol with the physical context 
of its intended environment and external systems. Through visualization of physical 
relationships, a better understanding can be gained about the system interactions and 
boundaries. Figure 14 shows the upper levels of the DAD system alongside the external 
systems associated with utilization of the DAD system for data transfer. Fourth level 
subsystems were shown on select third level subsystems to simplify the hierarchy 


diagram. 
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Figure 14. DAD System Hierarchy Diagram 


C. PACKAGE DIAGRAM 


The purpose of a package diagram is to support the organization of complex 
system architecture through ‘decomposed by’ (solid lines) or ‘ related to’ (dashed lines) 
relationships between elements packaged with unique identifiers (SysML.org 2020a). For 
this capstone, a mission planning package diagram was created to show the elements 
associated with using the DAD system for data transfer during a CSSQT. Figure 15 also 
shows how the DAD system fits into CSSQT execution. To keep in line with the scope of 
this capstone, the DAD system is shown as an additional method of data transfer, next to 
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currently used methods of satellite and hand-carrying data transfer. Combined with the 
high-level physical relationships identified in the hierarchy diagram, the non-physical 
relationships identified in this package diagram helps to visually represent the activities 


and entities involved with using the DAD system to transfer data during a CSSQT. 
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Figure 15. DAD System Mission Planning Package Diagram 


D. BLOCK DEFINITION DIAGRAM (BDD) 


The purpose of a BDD is to define the features of a block as properties, 
operations, and relationships; and relationships between blocks as associations and 
dependencies (No Magic, Inc. 2020). The BDDs shown in Figures 16 through 19 breaks 
down the DAD system into its subsystems and subcomponents. Additionally, the external 
actors are shown via aggregation. Figure 16 shows the DAD system decomposed into its 
three major subcomponents: the bolt-on UAV unit, ground-based modular computer 


subsystem, and ship-based modular computer subsystem. 
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Figure 16. High Level DAD System BDD 
46 


Figure 17 decomposes the bolt-on UAV unit into its respective subcomponents 
including the transmitter receiver, power supply, power distribution module, network 
switch, and central processing unit (CPU). An aggregation relationship between the UAV 


and bolt-on UAV unit are shown. 
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Figure 17. DAD Bolt-On UAV Subsystem BDD 


Figure 18 decomposes the ground-based modular computer subsystem into its 
respective subcomponents, including the CPU, KVM (Keyboard, Video, Mouse), and 
transmitter/receiver. Aggregation relationships with the ground-based operator and 


ground station power supply are shown. 
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Figure 18. DAD Ground-Based Subsystem BDD 
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Figure 19 decomposes the ship-based modular computer subsystem into its 
respective subcomponents, including the CPU, KVM, and transmitter/receiver. 


Aggregation relationships with the ship-based operator and shipboard power supply are 


shown. 
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Figure 19. DAD Ship-Based Subsystem BDD 


E. USE CASE DIAGRAM 


A use case diagram represents system transactions with external actors. System 
transactions are represented by ovals with action-oriented verbs or phrases, system 
boundaries are represented by rectangles and have unique identifiers, and actors are 
represented by stick-figures. Use case diagrams can also be used to identify top level 


requirements (SysML.org 2020d). 


Figure 20 shows the actors and transactions associated with the UAV launch and 
data upload to UAV boundaries. To simplify the diagram, top level actions were used 
within the shown system boundaries. For the UAV launch portion of the operational 
sequence, three main transactions were identified; equip UAV with bolt-on subsystem, 
prep UAV to launch, and launch UAV. The actors associated with the UAV launch 
transactions are the DAD team, launch team, and UAV pilot. For the data upload to UAV 
portion of the operational sequence, five main transactions were identified; pilot UAV, 
verify intercept location, upload data to the modular computer ship-based subsystem, 
upload data to bolt-on subsystem, download combat system (CS) data, and maintain bare 
steerage. The actors associated with this phase are the UAV pilot, DAD SME, bolt-on 


subsystem, ship-based modular computer subsystem, and ship’s force. 
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Figure 20. DAD System Use Case Diagram for Receive and Transmit 
Alternative 


F. ACTIVITY DIAGRAM 


An activity diagram is used to describe the control flow and object flow among 
actions. An action is defined as a primitive executable behavior, control flow is defined 
as the flow of functional behaviors, and object flow is defined as data flow of object 
inputs/outputs (SysML.org 2020e). In the activity diagram in Figure 21, actions are 
represented as white boxes, input/output are represented by green rectangles, and 


decision points are represented by white diamonds. The activity diagram flows from left 
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to right and different actors are shown by different ‘lanes. Actors include personnel as 


well as equipment. 


Figure 21 identifies the required actions for data upload and data transmission 
from the DAD SME, ship-based modular computer subsystem, bolt-on subsystem, UAV, 
UAV pilot, and SF. The data upload phase is initiated by verification of ‘intercept’ 
location by the DAD SME and the UAV pilot, or the location where the UAV is going to 
be positioned and be in range to communicate with the DAD ship-based modular 
computer subsystem. Once the location is determined/verified, the UAV pilot will 
maneuver the UAV to that location. Independent of those actions, the DAD SME will 
upload the CS data (removeable media previously obtained from SF) and verify if upload 
was successful. If upload was not successful, the DAD SME will attempt again or request 
another removeable media from SF. After CS data upload completion to the ship-based 
modular computer subsystem and arrival of the UAV on location, the DAD SME will 
establish a connection with the bolt-on subsystem and initiate data upload. The DAD 
SME will monitor upload status and upon completion will terminate connection with the 
bolt-on subsystem. Completion status will be relayed to the UAV pilot and the UAV pilot 
can then maneuver the UAV for ground station download. Due to variability of flight 


time without using a specific UAV, fuel consumption was not shown as a resource. 
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Data Upload to UAV (Receive and Transmit Alternative) 


Figure 21. 
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G. SEQUENCE DIAGRAM 


The purpose of a sequence diagram is to display sequential system interactions/ 
behaviors as messages between actors (SysML.org 2020c). A sequence diagram is similar 
to an activity diagram in that both show interactions between entities, but a sequence 
diagram does not show input or output. Figure 22 shows the required actions for data 
download from the UAV to the ground station. Actors include the bolt-on subsystem, 
DAD SME, ground-based modular computer subsystem, UAV, and UAV pilot. The data 
download phase has similar actions to the data upload phase, with the exception of 
communications between the bolt-on subsystem and the ground-based modular computer 


subsystem. Upon completion, the UAV can RTB or continue mission. 








Figure 22. DAD Sequence Diagram 
a2 


H. SUMMARY 


System architecture serves as the organization of system elements with each 
other, as well as the environment. The visual representation provided through each 
diagram created in Innoslate assist in communication of system interfaces, relationships, 
boundaries, and constraints. The capstone team referenced the DOD architecture 
framework 2.0 multi-step process as a guide to develop DAD system architecture (2020), 
based off the requirements identified in Chapter IV, Section D, Subsection 6. Combined, 
all provided diagrams describe upper and lower level relationships between the DAD 


system and external activities. 
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VI. MODELING AND SIMULATION 


A. MODELING METHODOLOGY 


The model used for this capstone was created using the modeling and simulation 
tool ExtendSim. The purpose of using ExtendSim for modeling and simulation was to (1) 
produce a model that was a representation of the intended construction of the Sol, (2) 
enable analyses to predict the effects of any changes made to the Sol, and (3) evaluate 
Sol behaviors and performance under different existing and proposed configurations 
(Maria 1997). The following steps to construct and execute the ExtendSim model was 


adapted from the Introduction to Modeling and Simulation (1997). 


1. Problem Identification 


Problem identification is discussed in Chapter I, Section C. 


2. Model Development 


The baseline model was developed with regards to real CSSQT scenarios. During 
a CSSQT on a controlled range, the ship is located within a specified number of miles 
offshore to enable communications with range safety and the test conductor. Proximity to 
shore allows for CS element data to be transferred and analyzed. The quantity of data that 


is typically transferred during any given CSSQT event was also taken into consideration. 


The baseline model represented ship’s current method for data transfer, satellite 
using Kurtz-unter (KU) band. The satellite scenario was the comparative control for 
amount of operational time required to transfer data from ship-to-shore. In the satellite 
model shown in Figure 23, the first function in the simulation was to set the file size to be 
transmitted. The second function was a human factor delay to account for establishing 
satellite connection. The data relay function was then used for calculating how long the 
data will take to transit based on data rates provided by Wells (2010) and file size for 
element data. The final function of the simulation was to tabulate the operational time 


and write it to a database for analysis, representing the data being received. 
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Figure 23. Satellite Baseline Model 


3. Model Validation 


Model validation was provided through research of existing and validated 
systems, SME and stakeholder feedback, as well as academic modeling and simulation 
SME feedback. Another method of model validation was comparison of simulation 
model outputs utilizing various input combinations, such as different data transfer 
technologies coupled with the different event condition inputs, such as human factor 


variations. 


4. Experimental Design and Simulation Conditions 


Three different data transfer scenarios utilizing UAVs were modeled. Simulation 
conditions included variations in human factor delays, data transfer capabilities, and time 
required for the UAV to maneuver from different locations. Simulation inputs also 
included variations in file size, UAV specifications, and distances from shore. Expected 
simulation outputs were data rates and operational times. Using these specific scenarios, 
data transfer technologies can be compared to show more coverage of current COTS 


capabilities. Statistical analysis of operational time and relation to specified variables 
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aided in understanding the benefits and risks associated with utilizing unmanned vehicles 


to transmit data. Alternatives are compared in Section C. 


a. UAV as a relay 


For this scenario, the bolt-on subsystem was used as a communication node, 
similar to the KU band method, where the data will be wirelessly transferred through the 
subsystem to the ground station. The relay scenario represented a case where the ship is 
in such a proximity that the ship-based subsystem can communicate with the ground- 
based subsystem. As shown in Figure 24, the first function in this simulation was to set 
the file size and the second function was to set the human factor delay. The next function 
included in the simulation was the UAV transit function. This function was an added 
delay that accounted for UAV operational time, including flight speed variation. The next 
function was a data relay delay based on data rate and file size for transmission. The final 
function of the simulation was the same as the satellite version where the data is written 
to a data table and processed for analysis. This model incorporated complications for 


UAV power transmission. 


Data 
Received 








Figure 24. UAV Relay Model 
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b. UAV wireless receive and transmit 


For this scenario, the data was wirelessly uploaded and stored on the bolt-on 
subsystem, then wirelessly transferred to the ground station. This scenario represented a 
case where the bolt-on subsystem had the required power transmission capacity for the 
specified data sizes, as well as UAV fuel capacity that supported the required transits and 
loiters. In Figure 25, the model incorporated functionality used in the UAV relay scenario 
but also accounts for additional time required for the UAV to transit to ground station 
proximity and transfer data. This scenario had a second human factor delay to account for 
the ground station operator establishing a connection with the bolt-on subsystem when 


the UAV is in proximity. 


Deta 
Download 





Figure 25. UAV Wireless Receive and Transmit Model 


c. UAV wireless receive and land 


For the UAV wireless receive and land scenario, the data was wirelessly uploaded 
and stored on a bolt-on subsystem hard drive, then recovered by ground station personnel 
after UAV RTB. This scenario represented cases where the power required for data 
transmission cannot be achieved due to system design constraints or where it is 
unfeasible for the UAV to transit back to ground station proximity for wireless data 


transfer. As shown in Figure 26, this scenario had model behavior similar to the UAV 
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wireless scenario, without the added time for data download and with the second human 


factor delay accounting for hard drive retrieval. 





Figure 26. UAV Wireless Receive and Land Model 


B. ALTERNATIVES ASSESSMENT 


This section continues the AoA that is described in the Chapter I. The capstone 
team analyzed the related ExtendSim models’ output data to determine overall UAV 
effectiveness as a replacement or as an augmentation to the existing methods of data 
transfer. For that reason, the focus was on operational time required to send and receive a 
file to compare the alternatives. The assessment consisted of an analysis of variance of 
means between different sets of output runs to determine model repeatability, descriptive 
statistics of the output relay times for the four models, and the regression analysis and 


factorial design of input factors to determine influence on the relay times themselves. 


1. Statistics 


The breakdown of analysis began with testability of the models. Using the data 
collection and analysis tool, Minitab, 2-sample t-tests were used to compare two separate 
100 output runs for each model against each other, to determine if the null hypothesis 
(sample mean | = sample mean 2) could or could not be rejected. Table 6 details the t-test 
metrics, including the p-values for each model. With an alpha value of 0.05, the p-values 
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show to be substantially greater, and the null hypothesis of equal means for multiple 100 
output runs of the same model cannot be rejected. While the modeling methodology 
highlights relay scenarios for 15GB, 100GB and 1000GB file sizes, the respective 
comparisons for 15GB file sizes is an appropriate analysis baseline to compare the UAV 


effectiveness to the current Satellite data transfer capabilities. 


Table 6. 2-Sample t-Test Results for Satellite and UAV Models’ Testability 





























Satellite (hrs) 0.47 180 0.64 No 

UAV Relay (hrs) 0.21 197 0.84 No 

UAV Receive and Land (hrs) 0.38 197 0.70 No 
UAV Receive and Transmit (hrs) 0.38 197 0.70 No 





The average time (in hours), along with the standard deviation and range of 100 
run time outputs for each model are shown in Table 7. These outputs consider a normal 
distribution of random inputs for each of the respective input factors. A clear observation 
would show that the satellite model takes well over three hours to completely send a 
package size of 1ISGB, while each of the UAV models show significant decreases in time 
required for data transfer. The UAV wireless receive and land and the UAV wireless 
receive and transmit models show similar outputs because the UAV loiter time provides 


the main action difference in the two models, providing little difference in variation. 


Table 7. Descriptive Statistics for Satellite and UAV Models’ Output Times 











for 15GB 
Satellite (hrs) 3.66 0.44 2.96 5.47 
UAV Relay (hrs) 0.52 0.15 0.29 0.79 
UAV Receive and Land (hrs) 1.28 0.30 0.80 1.88 
UAV Receive and Transmit (hrs) 1.32 0.30 0.83 1.92 
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2. Multivariant Regression Modeling 


In order to analysis the significance in outputs, it was important to examine the 
decomposition of the models themselves. With the existing method simulated in the 
satellite model. All input factors- the file size, human factor delay, and data transfer rate- 
were compared against the output of satellite data relay time. For the UAV related 
models, the inputs all remain the same- the fixed transit distance of the UAV between 
ground station and ship, the human factor delay, the UAV flight speed, the file size and 
the UAV data rate- which are compared to three different outputs for the three UAV 
models- UAV relay, UAV grab and land, and UAV grab and beam. 


Regression modeling determines the strength of relationship between the input 
factors and the output they are compared to. This helps determine if there is a level of 
predictability with all factors when the values are manipulated. Table 8 and Table 9 show 
the multivariable linear regression statistics tables for the satellite and UAV models, 
respectively, to highlight the regression values with the 100 model run observations. As 
the randomized inputs have shown, there proves to be no relationship to the output times 


themselves. Further analysis needed to be completed to examine the influence of each 























input. 
Table 8. Multivariable Linear Regression Statistics for Satellite Model 
Multiple R 0.12 
R Square 0.01 
Standard Error 0.15 
Observations 100 
Table 9. Multivariable Linear Regression Statistics for UAV Models 














Multiple R 0.0967 0.0978 0.0980 

R Squared 0.0094 0.0096 0.0096 
Standard Error | 0.1509 0.3086 0.3085 
Observations 100 100 100 

















3. Factorial Design 


The significance of input factors to a model can be dependent of the number of 
inputs present for the model itself. The fewer factors that contribute to the model, the 
more significance they hold in relation to the output’s value. Because the satellite model 
has two controllable, non-fixed factors and the UAV models have three controllable, non- 
fixed factors (file size is a fixed input), then a creation of factorial design of experiments 
(DOE) without the requirement of a screening for influential factors is needed. The 
Factorial DOE created looks at two factors at two levels for the satellite model, and three 
levels at two levels for the UAV models. Based on previous data collected through 


research and SME discussion, the two levels “High” and “Low” are shown in Table 10. 


Table 10. Level Values for Input Factors 


High 45 150 12 860 
Low 15 80 6 800 


























The factorial design highlights the influence of each input with a high and low 
value with the other respective inputs in a randomized pattern. These sequences of 100 
run samples are compared against each model, and against the default randomization of 


the four developed models. 
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Table 11. Factorial Design for Satellite and UAV Models’ Output 


HF LOW, UAV Speed 
RAN, UAV Data RAN 
HF HIGH, UAV Speed 
RAN, UAV Data RAN 
HF RAN, UAV Speed 
LOW, UAV Data RAN 
HF RAN, UAV Speed 
HIGH, UAV Data RAN 
HF RAN, UAV Speed 
RAN, UAV Data LOW 
HF RAN, UAV Speed 
RAN, UAV Data HIGH 

ALL UAV RANDOM 5 

(Normal) 
HF LOW, SAT Data RAN x 
HF HIGH, SAT Data x 
RAN 

HF RAN, SAT Data LOW xX 

x 

x 


0.29 0.81 0.85 





0.79 1.81 1.85 





0.54 1.42 1.46 


0.54 1,23 1.27 


x |x| mK | x | OK 


0.52 1.26 Lat 


0.35 1.28 1.32 x 


4.20 
4.66 
6.06 
3.30 











HF RAN, SAT Data 
HIGH 
ALL SAT RANDOM 
(Normal) 

















~ | Kx TX] OM LR] 
~ | Kx TX] OM [PR] 


4.45 











Across the satellite model sequences, the data rate levels show the largest 
difference in output mean to the default mean- with a respective min and max of 3.29 and 
6.06 hours against the default average of 4.45 hours. With the UAV model sequences, the 
human factor levels show the largest difference in output means to the default mean. 


Table 11 highlights the entirety of discussed values. 


Because of the large difference in data transfer rate, it is clear that as the required 
data transfer time decreases, the influence of the human factor delay increases. A 30- 
minute human factor delay will provide a larger variance from the output relay time mean 


on the quicker UAV model than the conventional, slower satellite model. 
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C. ALTERNATIVES COMPARISON 

In addition to statistical analysis, a comparison was performed between 
operational time and engineering complexity for each alternative solution at file sizes 15, 
100, and 1000 Gigabytes (GB). The inputs listed in Table 12 resulted in the outputs found 
in Table 13 by utilization of a function that included UAV transit time (UAV alternatives 


only) and data transfer time. 


Table 12. Comparison Inputs 























Distance from Shore (mi) 30 
UAV Speed (mph) 80-140 
File Size (GB) 15, 100, 1000 
Satellite Data Rate Variation (Mbps) 6-12 
UAV Data Rate Variation (Mbps) 800-860 
Human Factor Delay Variation (min) 5-15 








Table 13 shows a weighted comparison of all the alternative scenarios that were 
simulated. The operational time shows the averages of 100 runs in the simulations for 
each category of file size. The fastest method correlates to the smallest number of hours. 
Each scenario was also rated in terms of design complexity low, medium, or high. The 
best combination of these two parameters describe the best way to apply the use of a 


UAV for data transfer. 
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Satellite 


UAV Relay 


Table 13. Alternative Data Transfer Methods 


Deployed on current USN 


Power to transmit needs attention 
as well as hardware increase for 
dealing with longer distances to 

track the UAV. 





UAV Receive 
and Land 


Power to receive is a lot less than 

to transmit and landing the UAV 

saves time when getting the data 
to be analyzed. 





UAV Receive 
and Transmit 


Satellite 


UAV Relay 


Medium 


Power to transmit needs attention 
as well as requirements for the 
UAV platform like loiter time and 


Starts to put pressure on event 
schedules and mission capability if 
requirements have a time window. 
Power to transmit needs attention 

as well as hardware increase for 
dealing with longer distances to 
track the UAV. 





UAV Receive 
and Land 


Power to receive is a lot less than 

to transmit and landing the UAV 

saves time when getting the data 
to be analyzed. 





UAV Receive 
and Transmit 


Satellite 


Power to transmit needs attention 
as well as requirements for the 
UAV platform like loiter time and 


Puts massive strain on scheduling 
and takes too long for Navy 
mission. 





UAV Relay 


Power to transmit needs attention 
as well as hardware increase for 
dealing with longer distances to 

track the UAV and flight time 
starts to become a factor. 





UAV Receive 
and Land 


UAV Receive 
and Transmit 














Power to receive is a lot less than 

to transmit and landing the UAV 

saves time when getting the data 
to be analyzed. 

Power to transmit needs attention 
as well as requirements for the 
UAV platform like loiter time and 
range. 





‘0 - 2.0 hours is considered favorable for operational time and is highlighted as green. 2.0 - 5.0 
hours is considered less favorable for operational time and is highlighted as yellow. 5.0+ hours 
are considered least favorable for operational time and is highlighted as red. 


Engineering complexity was categorized into three levels: low, medium, and high. 
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D. SUMMARY 


This chapter detailed the approach taken to simulate alternative solutions in order 
to calculate the time it takes to transfer data from ship-to-shore. The capstone team 
developed four different models representing the alternatives discussed in Chapter HI. 
From the operational simulations, the capstone team performed statistical analysis for 
alternative comparison. The data presented variations of mean output time and concluded 
that regardless of delay time, the UAV operational time outputs showed significant 


improvements over the traditional satellite model. 
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Vil. CONCLUSION 


A. SUMMARY 


The primary objective of this project was to conduct a feasibility study to 
understand if a UAV can be used to improve the data transfer capability for the USN. 
From the literature review and knowledge gained from SMEs, the capstone team 
determined use of a UAV in ship-to-shore data transfer could provide benefit to the USN. 
The capstone team used defined initial system requirements, available research of 
communications systems, and available UAV characteristics to develop system 
architecture with the MBSE tool Innoslate. The utilization of MBSE tools supported the 
understanding and the ability to communicate interactions and functions of the DAD 


system within itself, external users, and the environment. 


The team identified several alternatives in which a UAV platform could be used 
as part of a system to supplement existing USN communication systems for data transfer. 
One alternative considered was to use wireless communications to get the data from the 
ship to a UAV bolt-on subsystem, then have the UAV transit to ground station proximity 
for wireless transmission of the data to a ground-based subsystem. In order to do this, it is 
required that the bolt-on subsystem have sufficient power to transmit the data the 
required distance, as well as the UAV have an endurance that supports the entire mission. 
The design constraint and platform constraint will have to be considered if the DAD 
system progresses through the acquisition life cycle. A second alternative considered was 
to utilize a UAV bolt-on subsystem to wirelessly receive data and store to an onboard 
hard drive, then RTB for hard drive retrieval. This method would avoid the design 
constraint for having sufficient power within the bolt-on subsystem for data transmission. 
The third alternative considered was to utilize the UAV as a relay, such that the bolt-on 
subsystem would be used as a node, similar to the current data transfer method of using a 
satellite. This concept would include the design constraint for transmission power, as well 
as limitations on data transfer technologies available to meet the required transmission 


distance. 
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The capstone team used ExtendSim to incorporate aspects of CSSQT scenarios to 
be able to analyze operational time outputs that represented variations in human and 
system performance. This operational time measurement was compared for each of the 
alternatives and showed the influence of the input factors to their respective model 


operational time outputs. 


B. FINDINGS 


This influence, identified through a factorial DOEs, showed the variation of mean 
output time by controlling different valued levels of their inputs, as well as identifying 
different influential factors for the satellite model versus the three alternative UAV 
models. As a final point of data analysis, in the factorial DOE the influence of the human 
factor delay showed that, regardless of the delay time, the UAV operational time outputs 
showed significant improvements over the satellite model. Table 14 through Table 16 
illustrate the percentage improvement of hours for each UAV model against the satellite 
model. All sequence columns relate to the factor level sequences in Value Modeling in 


Table 13. 


Table 14. Percentage Improvement (Time) UAV Relay vs. Satellite Relay 





























pe a 1446% | 531% 774% | 783% | 803% | 798% 
sara a 1605% | 589% phere eee | 892% | 886% 
ies 2089% | 767% ree e|ieeeee| 1161% | 1153% 
pao cee 1137% | 418% | 608% | 616% | 632% | 628% 
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Table 15. Percentage Improvement (Time) UAV Receive and Land vs. 
Satellite Relay 











en a 517% | 232% | 296% | 341% | 332% | 328% 
eee 574% | 257% | 328% | 378% | 368% | 364% 
a 747% | 335% | 427% | 492% | 480% | 473% 
eee 407% 182% | 232% | 268% | 261% | 258% 





























Table 16. Percentage Improvement (Time) UAV Receive and Transmit vs. 
Satellite Relay 











grey a 493% | 227% | 287% | 330% | 321% | 314% 
ages cag 547% | 252% | 319% | 366% | 357% | 348% 
poy a 712% | 328% | 415% | 477% | 464% | 453% 
pee ae 387% 178% | 226% | 259% | 253% | 247% 





























While all UAV alternatives with different input conditions provide significant 
improvements in data transfer capabilities by decreasing total operational time, there are 
a number of considerations for which options are both feasible and effective for the USN 
to consider implementing for future test events. These considerations include the 
engineering complexities and justifications listed in Table 13. While the alternative of 
using an UAV as a relay yields the shortest operational times, the engineering complexity 
with respect to transmit power and UAV loiter time have potential issues that have not 
been researched within the scope of this project. The alternative of using a UAV for 
receiving and landing yields significant improvements in operational time while the 
engineering complexity is low, as the transmit power issues do not exist. The receiving 


and landing alternative can permit the use of existing UAV platforms without extensive 
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research and developmental testing on transmitting power requirements. Additionally, a 
business case analysis can show the cost of suitable UAV platforms for this alternative- 
which increase when additional power requirements are not considered- the labor costs 
for UAV operational personnel and ship-based personnel, and any cybersecurity/ 
information assurance requirements for successfully conducted the data transfer 


scenarios. 


As shown in Tables 13 through 16, implementing any of the UAV alternatives 
would provide additional benefit with regards to data availability in a CSSQT 
application. The capability to provide larger amounts of data with reduced transfer times 
is invaluable in an operational environment, as it enables the ISEA to provide a faster 
turnaround for system analysis to support system reliability, maintainability, and 


availability. 


C. RECOMMENDATIONS 


There are several opportunities to improve the DAD system concept to close the 
data transfer gap and increase availability of data for the USN. For future effort, the 
capstone team recommends selecting an alternative from the proposed solutions (relay, 
receive and transmit, receive and land, or receive and transmit + land) for continued 
development. Selection of an alternative will enable identification of subsystem 


requirements, specific design constraints, and detailed design of the DAD system. 


The following list provides areas associated with this capstone that require further 
research and development, and potentially could serve as a topic for other capstones at 


NPS or command Naval Innovate Science and Engineering (NISE) projects: 


Application of the DAD system concept for other unmanned vehicle 
platforms (unmanned surface vehicle (USV) and/or extra-large unmanned 


underwater vehicle (XLUUV)) 


Application of microwave technology that can meet the range and future 


data rate needs of the USN 


70 


Integration into ship and/or unmanned vehicle platforms, with special 


regards to cybersecurity compliance 


Bolt-on subsystem design that fits the design constraints of a majority of 


UAV platforms 
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APPENDIX: RESEARCH NOT INCLUDED 
IN THE LITERATURE REVIEW 


Wang proposed a patent to augment wireless communication and satellite 
positioning for machines at a worksite including one or more unmanned aerial vehicles 
(UAV) configured to be remotely operated above an area encompassing the worksite 


(Wang and Rybski 2017). 


Li, Zhou and Lamont introduce four communication architectures for networking 
UAVs and review some military communication standards applicable to UAV 


communications (Li, Lamont, and Zhou 2013). 


Howard describes the development of a stand-alone unattended ground sensor 
used to process signals or data. The data collected is provided to a digital signal 
processing computer and then it’s sent to an UAV. He then states that UAVs make 


significant contributions to warfighting capability of operational forces and how they are 


The naval studies board conducted a high-level assessment with the goal of 
advising the Department of Navy on how to achieve Naval Command and Information 
Infrastructure (NCII) functional capabilities. This study defines multiple technical needs 
to transition to be a network centric force. The naval studies board explains that being 


network centric is a key element in the Navy’s transformation effort (Council 2000). 


In the Design for Maintaining Maritime Superiority, Admiral Gilday, defines key 
actions on how the United States Navy is going to be trying to grow. He states that the 
Navy will be tremendously challenged to match the changing threat landscape in this 


period of great power rivalry and rapid technical transition (CNO 2018). 


Kuleshov, Zaytseva, and Aksenov also considered using UAV routing algorithms 
as an implementation method for autonomous UAV interaction to search for best node 
positioning for uninterruptable transmission. The method, which involved an autonomous 
network of multiple UAVs, included using Active Data (AD) structure which could alter 
the data transmission process by controlling the network node’s hardware. An AD 


structure on a repeater UAV network allowed for an extensive transmission distance for 


oF) 


data transfer between RN nodes and applicable sinks (Kuleshov, A. Zaytseva, and 


Aksenov 2018). 


Zwerger, Pirker et al., introduced an alternative of quantum repeater for long- 
range quantum communication with improved scaling with the distance. The quantum 
repeater improved long scale quantum communication that handles channel errors and 


losses, as well as operational and memory errors (Zwerger et al. 2018). 


In Kam’s thesis, an autopilot guidance and control algorithm were developed 
which allowed relay vehicles to reposition themselves autonomously in order to maintain 
an optimal loitering flight path. This maximized the quality of the communication link 


between the command station and survey vehicle (Kam 2008). 
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